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Disclaimer 


e We are not Linux graphics stack developers (yet?); 
ə We are interested in (desktop/mobile) UI security; 


ə This presentation is based on our study and is (likely) 
incomplete (mostly focused on Linux); 


e Feel free to interrupt us. 
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Summary 


e Expected security properties & X-server 
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Confidentiality 


Use cases 0 & 1 
e The user is shopping online ; 
e He/she keys in the credit card number; 


ə A keylogger was installed on the computer 
or 
A program takes periodical screenshots; 


e His/her credit card number got stolen! 
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User's expectation towards confidentiality 


e Applications should never be able to access other applications’ 
input events or output buffers (allow only copy/paste); 


ə = Apps should not be able to eavesdrop other apps’ input 
events (keyloggers) nor their output buffers; 


ə —> This would make e-shopping safer on the system-side. 


X11 & X-server 


Grants full-access to whoever can read the magic cookie; 


© 
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Security model: Applications run by a user should be 
trusted. Isolation between users only; 


© 


Problem: applications cannot be trusted anymore and some 
apps can be launched behind the user's back; 


ə = This busts confidentiality! 
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Integrity 


ə The user is visiting his bank’s website; 
ə He/she checks the website address (https + right domain); 


e He/she is unaware that he/she is visiting a fake website and 
that Firefox's address bar has been redrawn by a malware; 


e His/her bank information got stolen! 
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User's expectation towards integrity 


e What is displayed is what the application drew; 
ə The events sent to the application are never tampered with; 


e — Applications should never be able to alter other 
applications’ output buffers or input events; 


> Help blocking Phishing-like attacks. 


X11 & X-server 


e Apps can inject input events (virtual keyboards); 


ə Apps with DRI 1 can render outside their “window” ; 
e — This busts integrity! 
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User's expectation towards availability 


ə Users think their computers do multitasking; 
ə Thus, one app shouldn't be able to bring the system down; 


ə = Applications should never be able to deny access to other 
applications. 


X11 & X-server 


ə Apps can act as screen lockers; 


ə Virtual keyboards may kill applications they want using 
XF86ClearGrab (the famous security hole of xserver 1.11); 


ə = This busts availability! 
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ə Provides a finer-grained access control in X11; 
ə Mostly per-feature access control with some clipboard control; 


ə XSELinux: Deactivated by default in Fedora/RHEL/CentOS 
as users are unconfined. 


e Use of sandbox services (Xephyr) recommended instead; 


ə — Still too coarse-grained to be fully useful. 


Isolate groups of applications into domains 


ə QubesOS : Isolation using virtual machines; 


ə PIGA-OS : Isolation using SELinux + XSELinux + 
PIGA-SYSTRANS; 


ə = Force applications to communicate via a controlled system. 
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QubesOS 


ə Allows the user to group applications into domains; 

ə Each domain requires a new Xen Virtual Machine (VM); 

ə Applications from the VM integrate with the original desktop 
but are outlined with a specific colour; 

ə A daemon in dom0 provides a mean of communication 
between the VMs and does Mandatory Access Control (MAC). 
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ə Allows defining activities and keep files separated (Taxes, 
e-shopping, private mails. .. ); 
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= À compromised domain cannot interfere with other VMs; 
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Uses Xen but could also use cgroup/LXC; 


© 


Provides a nicely-integrated GUI to ease setup. 


© 


Slow and resource heavy; 


© 


Hardware graphic acceleration limited to the number of GPU 
(with PCI passthrough which requires an IOMMU); 


Limited power management; 


© 
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Is Xen able to securely isolate VMs? 
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PIGA-OS 


Each applications is put inside a SELinux domain (Type); 
Files, processes, sockets are tagged with a SELinux label; 


A SELinux policy is set for every application and every activity; 


XSELinux is also used to restrict permissions inside the 
Xserver; 
A daemon (PIGA-SYSTRANS) grants rights as needed and 


prompts the user if he would like to enter a new domain 
depending on his/her activity. 
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PIGA-OS : Example domain Email 
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PIGA-OS : Example domain E-Shopping 
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ə No need for a virtual machine; 
ə We can use graphic acceleration for all apps! 


ə Dynamically adjusts applications’ permissions according to the 
user's activity (if the user agrees with it); 


e The model can be re-used if new confinement means appear; 


e Power management available. 


Requires SELinux and a SELinux policy; 


ə Finer-grained so harder to configure; 
No declassification method provided (yet?). 
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About Wayland/Weston 


Summary 


@ About Wayland/Weston 
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About Wayland/Weston 
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Input confidentiality 


ə Weston knows where applications are on the screen; 


e It decides which applications receive input events (currently 
selected, under the cursor...) = no broadcasting; 


ə = This defeats keyloggers. 


Input integrity 
e Weston does not receive input events from applications; 


e Input events can not be forged (access to /dev/(u)input 
restricted to the root user); 


ə — Virtual keyboards will be discussed later. 
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About Wayland/Weston 
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Output buffers confidentiality & integrity 


e Weston shares output buffers with applications using the GEM 
interface to limit buffer copy; 


ə The GEM handle is a 32bit integer; 
= This can be guessed or easily bruteforced! 


e Applications output buffers can be eavesdroped and modified. 


Possible solutions 
e Add access control to GEM (turn it into GEM2)? 
ə DMA-BUF for userspace? Access control in DMA-BUF? 
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About Wayland/Weston 
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Requirements 


e Applications shouldn't crash the compositor; 


ə Applications shouldn't deny access to other applications. 


Vulnerabilities 


ə Screenlocking; 


ə Any idea? 
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ə Unbypassable screen; 
ə Ask for a user secret or device to login; 


ə Enable users to switch or start new sessions. 


Recomendations 
ə Control which applications are able to lock the screen; 


e Make sure it uses PAM so we can extend loggin methods. 


About Wayland/Weston 
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Visual keyboards 


e They need to send input events to the compositor; 


ə Could be included into the compositor. 


Screenshot applications 


ə They need access to the global buffer; 


ə They can easily break confidentiality. 


Global shortcuts 
e Media players use global shortcuts to interact with the user; 


ə They should register key combos to the compositor in order to 
receive those events; 


e Where is the limit (keyloggers, user configured shortcuts)? 
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About Wayland/Weston 
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Mandatory Access Control 


ə Control enforced by the system (mostly the kernel); 


e Based on a policy (no unprivileged user control). 


Suggestions 


ə Should be implemented as a library to unify access control on 
every wayland compositors; 


ə Should define which applications are allowed to take 
screenshots/act as virtual keyboards/copy & paste/drag & 
drop/register global shortcuts. . . 


e Generic model, could look like or be polkit; 


e Integrating SELinux to use policy mecanisms. 
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About Wayland/Weston 
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ə Compositors have access to everything; 
ə They will only get bigger as the feature list grows; 


ə They will have vulnerabilities. 


What's blocking us? 


ə Input management; 


ə Output buffer management. 


Possible solution 


ə Separate the privileged code from the functional one; 


e Use UNIX sockets to forward file descriptors (drm + input). 
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Hardware/Driver security 


Summary 


© Hardware/Driver security 


Hardware/Driver security 


Requirements 


A driver/hw should not allow privilege escalation and should isolate 
GPU users: 


ə User ID; 
ə Confidentiality: read access to other buffers; 


ə Integrity: write access to other buffers. 


ə Good access control to the RAM and VRAM from the CPU: 


ə The GPU may provide read-write-access to the whole 
VRAM/Host RAM range to UNIX users through the use of 
Shaders/GPGPU/copy-engines (TEGRA 2); 


ə The nVidia driver allows users to access the GPU's registers. 
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Hardware/Driver security 
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Expose a secure API to the userland 


Goal: Users shouldn't be able to interfere with other GPU users 
ə The kernel should expose a sane API that isolate GPU users; 
ə This API should be the only way for a user to access the GPU; 


@ ++ no regs should be accessible from the userspace! 


Restrict GPU’s RAM access rights 


Goal: Deny access to the GPU to the kernel’s internal structures or 
other programs’ data. 


ə VGA window: The GPU can access the first 1.5MB of RAM; 
ə AGP aperture: Allow GPU access to a fixed part of the RAM; 


ə IOMMU: Programmable MMU for devices to grant RAM 
access as needeed where needed. 
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Hardware/Driver security 
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Driver /Hardware security : Current solutions 


Isolate users in a separate VM 


Goal: Restrict a GPU user to its own data by abstraction the 
memory address space 


Most secure solution; 
Increase context-switching delay (problem with DRI2 and Qt5) 
Currently used by: Nouveau (geforce 8+); 


Could also be used by: AMD (Southern Island+), Intel 
(Sandy Bridge+), ... 


26 / 30 


Hardware/Driver security 
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Driver/Hardware security : Current solutions 


Isolate users through Command Submission validation 


Goal: Restrict a GPU user to its own data by checking the 
commands issued by the user 


e Lower context-switching delay; 
ə Higher CPU usage in kernel space; 
ə Currently used by: Radeon, Intel; 


ə Can be used by: any driver on any card. 
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Driver/Hardware security : Possible solutions 


Zero buffer content at allocation time 


Goal: Restrict a GPU user to its own data by zeroing buffers at 
allocation time 


e Increase confidentiality; 

ə Prettier output; 

ə High-performance hit on memory-intensive applications; 
@ 


Solution: Zero un-used buffers when idle? 
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Hardware/Driver security 


Limits to per-GPU-user isolation 


e Driver/Hardware can provide isolation between GPU users; 


ə Compositors have access to applications’ output buffers; 
ə — The compositor and its plugins should also be secured. 


Compositor + plugins Interface 
Plugins shouldn't have access to buffers (when possible); 
Plugins shouldn't have access to inputs (when possible); 


We should make it hard for plugins to access output buffers; 


Buffers should be located at random addresses: 
Address-Space Layout Randomization (ASLR) in the driver? 


Applications generating a pagefault should be killed. 
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e Make it possible to implement activities and provide secure 
isolation between them (like QubesOS/PIGA-OS); 

e Allow the user to decide what he wants (per-application 
isolation vs performance?); 

ə Be ready for GPGPU shared clusters and the soon-to-come 
WebGL applications. 


No confidentiality/integrity between applications run by the 
same user: 
The Linux graphics stack make it possible to spy on users. 


Needed work 
e Increase isolation between GPU users. 
30 / 30 


Thank you for listening! 


Martin Peres: martin.peres@labri.fr 


Timothée Ravier: timothee.romain.ravier@gmail.com 


